@sbaldu The AMD CI runner has driver problems. I talk to the support. Don't care about the failed HIP runtime tests for the moment.

@sbaldu The AMD CI runner has driver problems. I talk to the support. Don't care about the failed HIP runtime tests for the moment.

Ok thanks. I see that the rest of the tests are passing.

@sbaldu The AMD CI runner has driver problems. I talk to the support. Don't care about the failed HIP runtime tests for the moment.

Ok thanks. I see that the rest of the tests are passing.

The problem still exist. I'm on it. It takes a little bit longer, because the administrator is in vacations and I'm working together with another administrator which overtakes it temporary.

@sbaldu Sorry, I did miss take. Your code has a bug. I can reproduce it locally.
It looks like a well know bug in the CI but the CI is working. I mixed up this PR with your other PR #2490 and therefore I thought your changes cannot break the tests. But the changes of the code of this PR looks like, that they can produce a dead look.

@sbaldu Sorry, I did miss take. Your code has a bug. I can reproduce it locally. It looks like a well know bug in the CI but the CI is working. I mixed up this PR with your other PR #2490 and therefore I thought your changes cannot break the tests. But the changes of the code of this PR looks like, that they can produce a dead look.

Ok thanks for the update. I'll fix it asap.

Now I'm looking at parts of alpaka I never read before :-D

I understand why you added the properties and flag to the QueueRegistry class - the CPU and CUDA/HIP devices have a shared_ptr to an instance of that class.

From a semantic (?) point of view, something called a QueueRegistry does not seem to be the right place for it :-/

@psychocoderHPC what do you think ?
I would rather avoid adding a second shared state, so reusing the QueueRegistry seems to make sense.
Maybe we could rename it to something more in line with the added features ?
What does this code look like in alpaka 3 ?

Instead, from a more technical point of view, I would prefer to move more of the common code to a reusable function, to avoid repetitions.

Could you try to move the setDeviceProperties directly in the class that owns the once_flag and the DeviceProperties, at least for the SYCL case ?

For the CPU and CUDA/HIP cases it seems more complicated.

ok now all the tests seem to be passing.
@SimeonEhrig @psychocoderHPC I renamed the QueueRegistry as DevGenericImpl, which is similar to the naming used for SYCL, is that ok?